perf(queue): claim the actuation lock before the refresh it exists to prevent - #10181

Closes #10174

The publish-and-maintain pass refreshed PR details and then asked "does another pass already own this PR?" — so every contended pass did the work and threw it away.

// before
if (otherRefreshReasons || reviewsCacheStale) await refreshPullRequestDetails(…)   // GitHub reads
const actuationLock = await claimPrActuationLock(…)
if (!actuationLock.acquired) { …audit…; throw ContendedError }                     // all discarded

// after
const actuationLock = await claimPrActuationLock(…)
if (!actuationLock.acquired) { …audit…; throw ContendedError }                     // bail before spending
if (otherRefreshReasons || reviewsCacheStale) await refreshPullRequestDetails(…)

Volume

github_app.pr_public_surface_lock_contended is the most frequent audit event on the Orb — 1,180 between 09:00 and 10:53 today, ~10/min, about 2× the next event:

 github_app.pr_public_surface_lock_contended   1180
 github_app.review_deferred_ci_pending          590
 github_app.miner_detection_cache_hit           529

Cost, stated precisely

refreshPullRequestDetails is itself cached — it consults the detail-sync state and reuses stored pull_request_files rows when the last sync covered the current head SHA. So a contention does not always cost a GitHub call, and I am not claiming 1,180 wasted API calls.

It always costs the sync-state reads plus shouldRefreshFilesForPreMergeChecks; on a cache miss it costs a token fetch plus the files/reviews fetch. That miss is what a busy PR produces — and a busy PR is also what contends, so the two peak together. This is the same window in which the installation hit API rate limit exceeded for installation ID 143010787 and 66 queue jobs stalled behind deferred_by: rate_limit.

Why this is safe

No semantic change. The lock's stated purpose (#9013) is to make "does another pass already own this PR" one question with one answer for the whole publish-then-maintain unit; asking it before the expensive part is strictly better.

Holding it across the refresh is already handled — #9467 renews the lock while work runs, precisely because this unit can span an AI review far longer than a refresh.

The second contention site (~7766) is deliberately untouched: it does not refresh beforehand, so it does not have this defect.

On the test asserting source order

Unusual, and deliberate. Both orderings behave identically on the happy path and differ only in what a losing pass spends before it throws — so no behavioural test can distinguish them. That is exactly why this drifted unnoticed.

Mitigations against the usual failure modes of such a test:

• anchored on the publish pass's own contention audit event, so an unrelated claimPrActuationLock elsewhere in this 16k-line file cannot satisfy it;
• a sanity assertion that both landmarks still exist, so a rename cannot make it pass vacuously;
• mutation-tested — reverting to the old ordering fails it.

Verification

Full suite 26,344 passed / 0 failed; typecheck, dead-exports, dead-source-files clean.